You are a chef
Data Availability ≠ Data Storageのおかげでデータ管理プラットフォーム(draft)で何を実現させたいかの全体像の説明がしやすくなったのと自分たちのポジションも明確になったと思うYudai.icon
Pipeleでの実装はデータを暗号化して保存して、アクセス制御が実装されている。
これはCanned foodにデータを入れる作業と同じ
Personal空間 = Canned food
IPFSの中に境界線を引きユーザーだけの空間を作成している
足りない部分
Canned foodを複数自分のと主張可能にする
1つのDIDでは実現可能だけど、複数のDIDを接続した際に、どのように異なるDIDで他のCanned foodを制御するのかって部分の設計が足りない
1つのCanned foodの中身をどれくらい出すかの量の指定をどうするか
1つのPersonal空間の中に複数のデータが入っている場合に、他のデータは見えないままにして目的のデータにのみアクセス可能にする
Cryptreeは1つ解決方法になりうる
そうなるとLit Protocolの実装では足りなさすぎる
つまり暗号化、復号化の実装を自分たちで0から実装する必要がある
= Nodeを建てたりとかなり多くの作業が必要になる可能性がある
1つ1つのデータごとに空間の作成を行う
これはまじで地獄だよね...Yudai.icon
鍵になるのはSymmetric LinkとAsymmetric Link
これによって量を指定することができる
Canned foodの中身の証明
なんのデータが入っているのか、どこで作成されたのか、正しいデータなのかの証明をする
= Universal APIの実現 = 全てのデータは検証可能
これ分散型台帳だからこそ実現可能なのではないか？
Write Access Cryptreeによって許可された人のみが書き込み、つまりはデータの保存や管理が可能
ここをユーザーが簡単に出来なくするなど色々と可能ではある
CIDの更新によっても分かる
誰によってが重要な場合、秘密分散法との組み合わせってかなりいい感じに出来そう
誰が書き込んだかの証明は可能
Buffetの期間
アクセス可能期間の設定を可能にする
これCodeによる規制可能性の重要な部分
dirty keyをどのように洗浄するか
技術的な部分もそうだけど、どう制約するのかの設計が大事やな
Yudai.iconここの部分考えよう
Cryptreeでは時間的な概念があるから可能そう
これらの実装が僕たちが行おうとしていること
なぜ必要なのかがData Availability ≠ Data Storageによって言語化がしやすくなった
データ管理プラットフォーム(draft)によってCanned foodからbuffetへ何を出すのかを選択するchefと同じなのである
つまりPersonal data => Commons data
「=>」には、選択だけではなくDifferential privacyやFederated learningの計算処理も含まれたりする
僕たちは秘密処理を次にやる or ハッカソンを開いたりする必要があるのか
エコシステムを拡げるためにYudai.icon
これって僕たちの方でライブラリー出せるんじゃね？？？Yudai.icon*2
ただCollective dataがどこに入ってくるのかがイメージ湧かなくなってきた
これに対してはPhilippeたちと対話を重ねながら探す